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Using the Secure Remote Password (SRP) Protocol for TLS Authentication 


Status of This Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 


Abstract 


This memo presents a technique for using the Secure Remote Password 
protocol as an authentication method for the Transport Layer Security 
protocol. 
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2. 


Introduction 


At the time of writing TLS [TLS] uses public key certificates, pre- 
shared keys, or Kerberos for authentication. 


These authentication methods do not seem well suited to certain 
applications now being adapted to use TLS ([IMAP], for example). 
Given that many protocols are designed to use the user name and 
password method of authentication, being able to safely use user 
names and passwords provides an easier route to additional security. 


SRP ([SRP], [SRP-6]) is an authentication method that allows the use 
of user names and passwords over unencrypted channels without 
revealing the password to an eavesdropper. SRP also supplies a 
shared secret at the end of the authentication sequence that can be 
used to generate encryption keys. 


This document describes the use of the SRP authentication method for 
TLS. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [REQ]. 


SRP Authentication in TLS 
1. Notation and Terminology 


The version of SRP used here is sometimes referred to as "SRP-6" 
[SRP-6]. This version is a slight improvement over "SRP-3", which 
was described in [SRP] and [SRP-RFC]. For convenience, this document 
and [SRP-RFC] include the details necessary to implement SRP-6; 
[SRP-6] is cited for informative purposes only. 
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This document uses the variable names defined in [SRP-60]: 
N, g: group parameters (prime and generator) 
S: Salt 
B, b: server's public and private values 
A, a: client's public and private values 
I: user name (aka "identity") 
P: password 
v: verifier 


k: SRP-6 multiplier 


The | symbol indicates string concatenation, the ^ operator is the 
exponentiation operation, and the $ operator is the integer remainder 
operation. 


Conversion between integers and byte-strings assumes the most 
Significant bytes are stored first, as per [TLS] and [SRP-RFC]. In 
the following text, if a conversion from integer to byte-string is 
implicit, the most significant byte in the resultant byte-string MUST 
be non-zero. If a conversion is explicitly specified with the 
operator PAD(), the integer will first be implicitly converted, then 
the resultant byte-string will be left-padded with zeros (if 
necessary) until its length equals the implicitly-converted length of 
N. 


2.2.  Handshake Protocol Overview 


The advent of [SRP-6] allows the SRP protocol to be implemented using 
the standard sequence of handshake messages defined in [TLS]. 


The parameters to various messages are given in the following 
diagram. 
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Client Server 
Client Hello (I)  -------- > 
Server Hello 
Certificate* 
Server Key Exchange (N, g, s, B) 
<-------- Server Hello Done 
Client Key Exchange (A) -------- > 
[Change cipher spec] 
Finished 2 |  -------- > 
[Change cipher spec] 
<-------- Finished 
Application Data <------- > Application Data 


* Indicates an optional message that is not always sent. 
Figure 1 
2.3. Text Preparation 


The user name and password strings SHALL be UTF-8 encoded Unicode, 
prepared using the [SASLPREP] profile of [STRINGPREP]. 


2.4. SRP Verifier Creation 


The verifier is calculated as described in Section 3 of [SRP-RFC]. 
We give the algorithm here for convenience. 


The verifier (v) is computed based on the salt (s), user name (I), 
password (P), and group parameters (N, g). The computation uses the 
[SHA1] hash algorithm: 


| 
n 
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m 
rm 
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Xs 
v= g9°x $N 


2.5. Changes to the Handshake Message Contents 
This section describes the changes to the TLS handshake message 
contents when SRP is being used for authentication. The definitions 


of the new message contents and the on-the-wire changes are given in 
Section 2.8. 


Taylor, et al. Informational [Page 5] 


RFC 5054 Using SRP for TLS Authentication November 2007 


2.5.1. Client Hello 


The user name is appended to the standard client hello message using 
the extension mechanism defined in [TLSEXT] (see Section 2.8.1). 
This user name extension is henceforth called the "SRP extension". 
The following subsections give details of its use. 


2.5.1.1. Session Resumption 


When a client attempts to resume a session that uses SRP 
authentication, the client MUST include the SRP extension in the 
client hello message, in case the server cannot or will not allow 
session resumption, meaning a full handshake is required. 


If the server does agree to resume an existing session, the server 
MUST ignore the information in the SRP extension of the client hello 
message, except for its inclusion in the finished message hashes. 
This is to ensure that attackers cannot replace the authenticated 
identity without supplying the proper authentication information. 


2.5.1.2. Missing SRP Extension 


The client may offer SRP cipher suites in the hello message but omit 
the SRP extension. If the server would like to select an SRP cipher 
suite in this case, the server SHOULD return a fatal 
"unknown psk identity" alert (see Section 2.9) immediately after 
processing the client hello message. 


A client receiving this alert MAY choose to reconnect and resend the 
hello message, this time with the SRP extension. This allows the 
client to advertise that it supports SRP, but not have to prompt the 
user for his user name and password, nor expose the user name in the 
Clear, unless necessary. 


2.5.1.3. Unknown SRP User Name 


If the server doesn’t have a verifier for the user name in the SRP 
extension, the server MAY abort the handshake with an 
"unknown_psk_identity" alert (see Section 2.9). Alternatively, if 
the server wishes to hide the fact that this user name doesn’t have a 
verifier, the server MAY simulate the protocol as if a verifier 
existed, but then reject the client’s finished message with a 
"bad_record_mac" alert, as if the password was incorrect. 


To simulate the existence of an entry for each user name, the server 
must consistently return the same salt (s) and group (N, g) values 
for the same user name. For example, the server could store a secret 
"seed key" and then use HMAC-SHA1 (seed key, "salt" | user_name) to 
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generate the salts [HMAC]. For B, the server can return a random 
value between 1 and N-1 inclusive. However, the server should take 
care to simulate computation delays. One way to do this is to 


generate a fake verifier using the "seed key" approach, and then 
proceed with the protocol as usual. 


2.5.2. Server Certificate 


The server MUST send a certificate if it agrees to an SRP cipher 
suite that requires the server to provide additional authentication 
in the form of a digital signature. See Section 2.7 for details of 
which cipher suites defined in this document require a server 
certificate to be sent. 


2.5.3. Server Key Exchange 


The server key exchange message contains the prime (N), the generator 
(g), and the salt value (s) read from the SRP password file based on 
the user name (I) received in the client hello extension. 


The server key exchange message also contains the server's public 
value (B). The server calculates this value as B = k*v + g^b $ N, 
where b is a random number that SHOULD be at least 256 bits in length 


and k = SHA1(N | PAD(g)). 


If the server has sent a certificate message, the server key exchange 
message MUST be signed. 


The group parameters (N, g) sent in this message MUST have N as a 
safe prime (a prime of the form N-2q-*1, where q is also prime). The 
integers from 1 to N-1 will form a group under multiplication $ N, 
and g MUST be a generator of this group. In addition, the group 
parameters MUST NOT be specially chosen to allow efficient 
computation of discrete logarithms. 


The SRP group parameters in Appendix A satisfy the above 
requirements, so the client SHOULD accept any parameters from this 
appendix that have large enough N values to meet her security 
requirements. 


The client MAY accept other group parameters from the server, if the 
client has reason to believe that these parameters satisfy the above 
requirements, and the parameters have large enough N values. For 
example, if the parameters transmitted by the server match parameters 
on a "known-good" list, the client may choose to accept them. See 
Section 3 for additional security considerations relevant to the 
acceptance of the group parameters. 
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Group parameters that are not accepted via one of the above methods 
MUST be rejected with an "insufficient security" alert (see 
Section 2.9). 


The client MUST abort the handshake with an "illegal parameter" alert 
if B % N= 0. 


2.5.4. Client Key Exchange 


The client key exchange message carries the client's public value 


9 


(A). The client calculates this value as A = g^a $ N, where a is a 
random number that SHOULD be at least 256 bits in length. 


The server MUST abort the handshake with an "illegal parameter" alert 
if A $ N= 0. 


2.6. Calculating the Premaster Secret 


The premaster secret is calculated by the client as follows: 


I, P = «read from user» 

N, g, S, B = «read from server» 

a = random() 

A-g^a$N 

u = SHA1(PAD(A) | PAD(B)) 

k = SHA1(N | PAD(g)) 

x = SHAl(s | SHA1(I | ":" | P)) 

<premaster secret» = (B - (k * g^x)) ^ (a + (u * x)) $N 


The premaster secret is calculated by the server as follows: 
, 9r S, V = <read from password file> 

= random () 

SHA1(N | PAD(g)) 

= k*v + g^b $ N 

= <read from client> 

= SHA1(PAD(A) | PAD(B)) 

<premaster secret» = (A * v^u) ^ b $ N 


empumwoz 
ll 


The finished messages perform the same function as the client and 
server evidence messages (M1 and M2) specified in [SRP-RFC]. If 
either the client or the server calculates an incorrect premaster 
secret, the finished messages will fail to decrypt properly, and the 
other party will return a "bad_record_mac" alert. 


If a client application receives a "bad_record_mac" alert when 


performing an SRP handshake, it should inform the user that the 
entered user name and password are incorrect. 


Taylor, et al. Informational [Page 8] 


RFC 5054 Using SRP for TLS Authentication November 2007 
2.7.  Ciphersuite Definitions 
The following cipher suites are added by this document. The usage of 


Advanced Encryption Standard (AES) 


[AESCIPH]. 


CipherSuite TLS SRP 


CipherSuite 
CipherSuite 
CipherSuite 
CipherSuite 
CipherSuite 
CipherSuite 
CipherSuite 


CipherSuite 


TLS 


TLS 


TLS 


TLS 


TLS 


TLS 


TLS 


TLS 


cipher suites is as defined in 


WITH 3DES EDE CBC SHA = { 0OxCO,0x1A }; 


( OxCO,O0x1B }; 


{ 0xCO,O0x1C }; 


CBC SHA = { OxCO,0xl1D }; 


128 CBC SHA = { O0OxCO,0xlE }; 


( OxCO,O0x1F }; 


CBC SHA = ( 0xC0, 0x20 }; 


( 0xC0,0x21 }; 


IA 
SRP iA RSA WITH 3DES EDE CBC SHA 
SRP iA DSS WITH 3DES EDE CBC SHA 
SRP A WITH AES 128 
SRP IA RSA WITH AES 
SRP iA DSS WITH AES 128 CBC SHA 
SRP iA WITH AES 256 
SRP iA RSA WITH AES 256 CBC SHA 
SRP SHA DSS WITH AES 


256 CBC SHA = ( 0xC0, 0x22 }; 


Cipher suites that begin with TLS SRP SHA RSA or TLS SRP SHA DSS 
to send a certificate message containing a 
certificate with the specified type of public key, and to sign the 
server key exchange message using a matching private key. 


require the server 


Cipher suites that do not include a digital signature algorithm 
identifier assume that the server is authenticated by its possession 
of the SRP verifier. 


Implementations conforming to this specification MUST implement the 
TLS SRP SHA WITH 3DES EDE CBC SHA cipher suite, SHOULD implement the 


TLS SRP SHA WITH AES 128 CBC SHA and TLS SRP SHA WITH AES 256 CBC SHA 


cipher suites, 


2.8. New Message Structures 


and MAY implement the remaining cipher suites. 


This section shows the structure of the messages passed during a 
handshake that uses SRP for authentication. The representation 
language used is the same as that used in [TLS]. 


Taylor, et al. 


Informati 


onal 


[Page 9] 


RFC 5054 Using SRP for TLS Authentication November 2007 


2.8.1. Client Hello 
A new extension "srp", with value 12, has been added to the 
enumerated ExtensionType defined in [TLSEXT]. This value MUST be 
used as the extension number for the SRP extension. 


The "extension data" field of the SRP extension SHALL contain: 


opaque srp I«1..2^8-1»; 


where srp I is the user name, encoded per Section 2.3. 
2.8.2. Server Key Exchange 


A new value, "srp", has been added to the enumerated 
KeyExchangeAlgorithm originally defined in [TLS]. 


When the value of KeyExchangeAlgorithm is set to "srp", the server's 
SRP parameters are sent in the server key exchange message, encoded 
in a ServerSRPParams structure. 


If a certificate is sent to the client, the server key exchange 
message must be signed. 


enum { rsa, diffie hellman, srp ) KeyExchangeAlgorithm; 


struct { 
select (KeyExchangeAlgorithm) { 

case diffie_hellman: 
ServerDHParams params; 
Signature signed_params; 

case rsa: 
ServerRSAParams params; 
Signature signed_params; 

case srp: /* new entry */ 
ServerSRPParams params; 
Signature signed_params; 


h 
) ServerKeyExchange; 


struct { 
opaque srp N«1..2^16-1»; 
opaque srp g«1..2^16-1»; 
opaque srp s«1..2^8-1»; 
opaque srp B«1..2^16-1»; 
) ServerSRPParams; /* SRP parameters */ 
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2.8.3. Client Key Exchange 


When the value of KeyExchangeAlgorithm is set to "srp", the client's 
public value (A) is sent in the client key exchange message, encoded 
in a ClientSRPPublic structure. 


struct { 
select (KeyExchangeAlgorithm) { 
case rsa: EncryptedPreMasterSecret; 
case diffie hellman: ClientDiffieHellmanPublic; 
case srp: ClientSRPPublic; /* new entry */ 
) exchange keys; 
) ClientKeyExchange; 


struct { 
opaque srp A«1..2^16-1»; 
) ClientSRPPublic; 


2.9. Error Alerts 
This document introduces four new uses of alerts: 


o "unknown psk identity" (115) - this alert MAY be sent by a server 
that would like to select an offered SRP cipher suite, if the SRP 
extension is absent from the client's hello message. This alert 
is always fatal. See Section 2.5.1.2 for details. 


o "unknown psk identity" (115) - this alert MAY be sent by a server 
that receives an unknown user name. This alert is always fatal. 
See Section 2.5.1.3 for details. 


o "insufficient security" (71) - this alert MUST be sent by a client 
that receives unknown or untrusted (N, g) values. This alert is 
always fatal. See Section 2.5.3 for details. 


o "illegal parameter" (47) - this alert MUST be sent by a client or 
server that receives a key exchange message with A % N= 0 or B & 
N= 0. This alert is always fatal. See Section 2.5.3 and 
Section 2.5.4 and for details. 


The "insufficient_security" and "illegal_parameter" alerts are 


defined in [TLS]. The "unknown psk identity" alert is defined in 
[PSK]. 
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3. Security Considerations 
3.1. General Considerations for Implementors 


The checks described in Section 2.5.3 and Section 2.5.4 on the 
received values for A and B are CRUCIAL for security and MUST be 
performed. 


The private values a and b SHOULD be at least 256-bit random numbers, 
to give approximately 128 bits of security against certain methods of 
calculating discrete logarithms. See [TLS], Section D.1, for advice 

on choosing cryptographically secure random numbers. 


3.2. Accepting Group Parameters 


An attacker who could calculate discrete logarithms $ N could 
compromise user passwords, and could also compromise the 
confidentiality and integrity of TLS sessions. Clients MUST ensure 
that the received parameter N is large enough to make calculating 
discrete logarithms computationally infeasible. 


An attacker may try to send a prime value N that is large enough to 
be secure, but that has a special form for which the attacker can 
more easily compute discrete logarithms (e.g., using the algorithm 
discussed in [TRAPDOOR]). If the client executes the protocol using 
such a prime, the client's password could be compromised. Because of 
the difficulty of checking for such primes in real time, clients 
SHOULD only accept group parameters that come from a trusted source, 
such as those listed in Appendix A, or parameters configured locally 
by a trusted administrator. 


3.3. Protocol Characteristics 


If an attacker learns a user's SRP verifier (e.g., by gaining access 
to a server's password file), the attacker can masquerade as the real 
server to that user, and can also attempt a dictionary attack to 
recover that user's password. 


An attacker could repeatedly contact an SRP server and try to guess a 
legitimate user's password. Servers SHOULD take steps to prevent 
this, such as limiting the rate of authentication attempts from a 
particular IP address or against a particular user name. 


The client's user name is sent in the clear in the Client Hello 
message. To avoid sending the user name in the clear, the client 
could first open a conventional anonymous or server-authenticated 
connection, then renegotiate an SRP-authenticated connection with the 
handshake protected by the first connection. 
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If the client receives an "unknown psk identity" alert in response to 
a client hello, this alert may have been inserted by an attacker. 

The client should be careful about making any decisions, or forming 
any conclusions, based on receiving this alert. 


It is possible to choose a (user name, password) pair such that the 
resulting verifier will also match other, related, (user name, 


password) pairs. Thus, anyone using verifiers should be careful not 
to assume that only a single (user name, password) pair matches the 
verifier. 

3.4. Hash Function Considerations 


This protocol uses SHA-1 to derive several values: 


Oo Uu prevents an attacker who learns a user's verifier from being 
able to authenticate as that user (see [SRP-6]). 


O k prevents an attacker who can select group parameters from being 
able to launch a 2-for-1 guessing attack (see [SRP-6]). 


o Xx contains the user's password mixed with a salt. 


Cryptanalytic attacks against SHA-1 that only affect its collision- 
resistance do not compromise these uses. If attacks against SHA-1 
are discovered that do compromise these uses, new cipher suites 
should be specified to use a different hash algorithm. 


In this situation, clients could send a Client Hello message 
containing new and/or old SRP cipher suites along with a single SRP 
extension. The server could then select the appropriate cipher suite 
based on the type of verifier it has stored for this user. 


4. IANA Considerations 
This document defines a new TLS extension "srp" (value 12), whose 


value has been assigned from the TLS ExtensionType Registry defined 
in [TLSEXT]. 


This document defines nine new cipher suites, whose values have been 
assigned from the TLS Ciphersuite registry defined in [TLS]. 


CipherSuite TLS SRP SHA WITH 3DES EDE CBC SHA = { O0xCO,0x1A }; 


CipherSuite TLS SRP SHA RSA WITH 3DES EDE CBC SHA ( OxCO,O0x1B }; 


CipherSuite TLS SRP SHA DSS WITH 3DES EDE CBC SHA 


{ 0xCO,O0x1C }; 
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CipherSuite TLS SRP SHA WITH AES 128 CBC SHA = { 0xC0,0x1D Jj; 
CipherSuite TLS SRP SHA RSA WITH AES 128 CBC SHA = { 0xC0,0x1E }; 
CipherSuite TLS SRP SHA DSS WITH AES 128 CBC SHA = { O0OxCO,0xlF }; 
CipherSuite TLS SRP SHA WITH AES 256 CBC SHA = { 0xC0, 0x20 }; 
CipherSuite TLS SRP SHA RSA WITH AES 256 CBC SHA = ( 0xC0,0x21 }; 
CipherSuite TLS SRP SHA DSS WITH AES 256 CBC SHA = ( 0xC0,0x22 }; 
5. References 
5.1. Normative References 
[REQ] Bradner, S., "Key words for use in RFCs to Indicate 


[TLS] 


[TLSEXT ] 


[STRINGPREP ] 


[SASLPREP ] 


[SRP-RFC] 


[SHA1] 


[HMAC] 


[AESCIPH] 


Taylor, et al. 


Requirement Levels", BCP 14, RFC 2119, March 1997. 


Dierks, T. and E. Rescorla, "The TLS Protocol version 
1.1", RFC 4346, April 2006. 


Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, 
J., and T. Wright, "Transport Layer Security (TLS) 
Extensions", RFC 4366, April 2006. 


Hoffman, P. and M. Blanchet, "Preparation of 
Internationalized Strings ("stringprep")", RFC 3454, 
December 2002. 


Zeilenga, K., "SASLprep: Stringprep profile for user 
names and passwords", RFC 4013, February 2005. 


Wu, T., "The SRP Authentication and Key Exchange 
System", RFC 2945, September 2000. 


"Secure Hash Standard (SHS)", FIPS 180-2, August 2002. 
Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: 
Keyed-Hashing for Message Authentication", RFC 2104, 
February 1997. 

Chown, P., "Advanced Encryption Standard (AES) 


Ciphersuites for Transport Layer Security (TLS)", 
RFC 3268, June 2002. 


Informational [Page 14] 


RFC 5054 Using SRP for TLS Authentication November 2007 


[PSK] Eronen, P. and H. Tschofenig, "Pre-Shared Key 
Ciphersuites for Transport Layer Security (TLS)", 
RFC 4279, December 2005. 


[MODP] Kivinen, T. and M. Kojo, "More Modular Exponentiation 
(MODP) Diffie-Hellman groups for Internet Key Exchange 
(IKE)", RFC 3526, May 2003. 


5.2. Informative References 


[ IMAP ] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 
RFC 2595, June 1999. 


[SRP-6] Wu, T., "SRP-6: Improvements and Refinements to the 
Secure Remote Password Protocol", Submission to IEEE 
P1363.2 working group, October 2002, 
«http://grouper.ieee.org/groups/1363/». 


[SRP] Wu, T., "The Secure Remote Password Protocol", 
Proceedings of the 1998 Internet Society Network and 
Distributed System Security Symposium pp. 97-111, 
March 1998. 


[TRAPDOOR] Gordon, D., "Designing and Detecting Trapdoors for 


Discrete Log Cryptosystems", Springer-Verlag Advances 
in Cryptology - Crypto '92, pp. 66-75, 1993. 


Taylor, et al. Informational [Page 15] 


RFC 5054 Using SRP for TLS Authentication 


Appendix A.  SRP Group Parameters 


The 


developed by Tom Wu and Eugene 


November 2007 


1024-, 1536-, and 2048-bit groups are taken from software 


distribution, and subsequently proven to be prime. 


are 


primitive roots of N, 


The 1024-bit and 1536-bit groups MUST be supported. 


1. 


Taylor, 


1024-bit Group 
The hexadecimal value for the 


EEAFOAB9 ADB38DD6 9C33F80A 
9C256576 D674DF74 96EA81D3 
8E495C1D 6089DAD1 5DC7D7B4 
7BCF1885 C529F566 660E57EC 
FD5138FE 8376435B 9FC61D2F 


The generator is: 2. 
1536-bit Group 
The hexadecimal value for the 


9DEF3CAF B939277A B1F12A86 
4B19CC4D 5F4F5F55 6E27CBDE 
80B655BB 9A22E8DC DF028A7C 
E3BAB63D 47548381 DBC5BIFC 
6EDF0195 39349627 DB2FD53D 
F7CCB7AE 837C264A E3A9BEB8 
8CE7A28C 2442C6F3 15180F93 


The generator is: 2. 


prime is: 


FA8FC5E8 
383B4813 
6154D6B6 
68EDBC3C 
COEBO6E3 


prime is: 


17A47BBB 
51C6A94B 
EC67FODO 
764E3F4B 
24B7C486 
TE 8A2FE9 
499A234D 


et al. Informational 


60726187 
D692C6E0 
CE8EF4AD 
05726CCO 


DBA51DF4 
E4607A29 
8134B1C8 
53DD9DA1 
65772E43 
B8B5292E 
CF76E3FE 


Jhong for the Stanford SRP 


The larger primes 
taken from [MODP], but generators have been calculated that are 


unlike the generators in [MODP]. 


75FF3COB 
EOD5D8E2 
69B15D49 
2FD4CBF4 


99AC4C80 
1558903B 
B9798914 
158BFD3E 
7D6C7F8C 
5A021FFF 
D135F9BB 


9EA2314C 
50B98BE4 
82559B29 
976EAA9A 


BEEEA961 
AODOF843 
9B609E0B 
2B9C8CF5 
E442734A 
5E91479E 
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3. 2048-bit Group 


The hexadecimal value for the 


AC6BDB41 
3DB56050 
CD7F48A9 
D5FAAAE8 
7359D041 
436C6481 
5EAT77A2'1 
03CE5329 
94B5C803 
9EA4AFF73 


324A9A9B 
A37329CB 
DAO4FD50 
2918A996 
D5C33EA7 
F1D2B907 
75D2ECFA 
9CCC041C 
D89F7AE4 


F166DE5E 
B4A099ED 
E8083969 
2F0B93B8 
1D281EA44 
8717461A 
032CFBDB 
7BC308D8 
35DE236D 


prime is: 


1389582F AF72B665 
8193E075 776 7A13D 
EDB767B0 CF609517 
55F97993 EC975EEA 
6B14773B CA97B43A 
5B9D32E6 88F87748 
F52FB378 61602790 
2A5698F3 A8D0C382 
525F5475 9B65E372 


1987EE07 
D52312AB 
9A163AB3 
A80D740A 
23FB8016 
544523B5 
04E57AE6 
71AE35F8 
FCD68EF2 


FC319294 
4B03310D 
661A05FB 
DBFAFF74 
76BD207A 
24B0D57D 
AF874E73 
E9DBFBB6 
OFA7111F 


The generator is: 2. 
4. 3072-bit Group 


This prime is: 
1690314 } 


2^3072 - 2^3008- 1 + 2^64 * ( [2^2942 pi] + 


Its hexadecimal value is: 


Taylor, 


FFFFFFFF 
8A67CC74 
302B0A6D 
A637ED6B 
49286651 
FD24CF5F 
670C354E 
180E8603 
3995497C 
04507A33 
B3970F85 
1AD2EE6B 
BBE11757 
EOFD108E 


FFFFFFFF 
020BBEA6 
F25F1437 
OBFF5CB6 
ECE45B3D 
83655D23 
4ABC9804 
9B2783A2 
EA956AE5 
A85521AB 
A6E1E4C7 


C90FDAA2 
3B139B22 
4FE1356D 


2168C234 C4C6628B 
514A0879 8E3404DD 
6D51C245 E485B576 


F406B7ED 


EE386BFB 5A899FA5 


C2007CB8 
DCA3AD96 
F1746C08 
ECO7A28F 
15D22618 
DF1CBA64 
ABF 5AE8C 


F12FFAO06 
7A615D6C 
4B82D120 


The generator is: 


et al. 


Je 


D98A0864 
770988C0 
A93AD2CA 


A163BF05 98DA4836 
1C62F356 208552BB 
CA18217C 32905E46 


80DC1CD1 
EF 9519B3 
625E7EC6 
AE9F2411 
1C55D39A 
9ED52907 
2E36CE3B 


29024E08 
CD3A431B 
F44C42E9 
7CABIFEG 
69163FA8 
7096966D 
E39E772C 


B5C55DFO0 6F4C52C9 
98FA0510 15728E5A 
ECFB8504 58DBEFOA 
DB0933D7 1E8C94E0 
D8760273 3EC86A64 
BAD946E2 08E24FA0 
FFFFFFFF FFFFFFFF 


Informational 


DE2BCBF6 
8AAACA2D 
8AEA7157 
4A25619D 
521F2B18 
74E5AB31 


95581718 
AD33170D 
5D060C7D 
CEE3D226 
177B200C 
43DB5BFC 
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5. 4096-bit Group 


This prime is: 


240904 } 


Its hexadecimal value is: 


FFFFFFFF 
8A67CC74 
302B0A6D 
A637ED6B 
49286651 
FD24CF5F 
670C354E 
180E8603 
3995497C 
04507A33 
B3970F85 
1AD2EE6B 
BBE11757 
EOFD108E 
99C32718 
O4DE8EF9 
233BA186 
D5B05AA9 
FFFFFFFF 


FFFFFFFF 
020BBEA6 
F25F1437 
OBFF5CB6 
ECE45B3D 
83655D23 
4ABC9804 
9B2783A2 
EA956AE5 
A85521AB 


C90FDAA2 
3B139B22 
4FE1356D 
F406B7ED 
C2007CB8 
DCA3AD96 
F1746C08 
ECO7A28F 
15D22618 
DF1CBA64 


2^4096 - 2^4032 - 1+ 2^64 * { 


2168C234 
514A0879 
6D51C245 
EE386BFB 
A163BF05 
1C62F356 
CA18217C 
B5C55DF0 
98FA0510 
ECFB8504 


A6E1E4C7 


ABF 5AE8C 


F1I2FFA06 
7A615D6C 
4B82D120 
6AF4E23C 
2E8EFC14 
515BE7ED 
93B4EA98 
FFFFFFFF 


The generator is: 5. 


Taylor, 


et al. 


D98A0864 
770988C0 
A9210801 
1A946834 
1FBECAA6 
1F612970 
8D8FDDC1 


DB0933D7 
D8760273 
BAD946E2 
1A723C12 
B6150BDA 
287C5947 
CEE2D7AF 
86FFB7DC 


Informational 


C4C6628B 
8E3404DD 
E485B576 
5A899FA5 
98DA4836 
208552BB 
32905E46 


November 2007 


80DC1CD1 
EF 9519B3 
625E7EC6 
AE9F2411 
1C55D39A 
9ED52907 
2E36CE3B 


[2^3966 pi] + 


29024E08 
CD3A431B 
F44C42E9 
7CABIFEG 
69163FA8 
7096966D 
E39E772C 


6F4C52C9 
15728E5A 
58DBEFOA 
1E8C94E0 
3EC86A64 
08E24FAO0 
A787E6D7 
2583E9CA 
4E6BCO5D 
B81BDD76 
90A6CO8F 


DE2BCBF6 
8AAACA2D 
8AEA7157 
4A25619D 
521F2B18 
74E5AB31 
88719A10 
2AD44CE8 
99B2964F 
2170481C 
4DF435C9 


95581718 
AD33170D 
5D060C7D 
CEE3D226 
177B200C 
43DB5BFC 
BDBA5B26 
DBBBC2DB 
A090C3A2 
D0069127 
34063199 
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6. 6144-bit Group 


This prime is: 


929484 ] 


Its hexadecimal value is: 


FFFFFFFF 
8A67CC74 
302B0A6D 
A637ED6B 
49286651 
FD24CF5F 
670C354E 
180E8603 
3995497C 
04507A33 
B3970F85 
1AD2EE6B 
BBE11757 
EOFD108E 
99C32718 
O4DE8EF9 
233BA186 
D5B05AA9 
36C3FAB4 
AD9E530E 


FFFFFFFF 
020BBEA6 
F25F1437 
OBFF5CB6 
ECE45B3D 
83655D23 
4ABC9804 
9B2783A2 
EA956AE5 
A85521AB 
A6E1E4C7 


C90FDAA2 
3B139B22 
4FE1356D 
F406B7ED 
C2007CB8 
DCA3AD96 
F1746C08 
ECO7A28F 
15D22618 
DF1CBA64 
ABF 5AE8C 


F1I2FFA06 
7A615D6C 
4B82D120 
6AF4E23C 
2E8EFC14 
515BE7ED 
93B4EA98 
D27C7026 
E5DB382F 


DA3EDBEB 
2BD7AF 42 
F482D7CE 
BEC7E8F3 
CC8F6D7E 
B7C5DA76 
387FE8D7 
6DCC4024 


CF 9B14ED 
6FB8F401 
6E74FEF6 
23A97A7E 
BF48E1D8 
F550AA3D 
6E3C0468 
FFFFFFFF 


The generator is: 5. 


Taylor, 


et al. 


D98A0864 
770988C0 
A9210801 
1A946834 
1FBECAA6 
1F612970 
8D8FDDC1 
C1D4DCB2 
413001AE 
44CE6CBA 
378CD2BF 
D55E702F 
36CC88BE 
14CC5ED2 
8AIFBFFO 
043E8F66 
FFFFFFFF 


2^6144 - 2^6080- 1 + 2^64 * { 


2168C234 
514A0879 
6D51C245 
EE386BFB 
A163BF05 
1C62F356 
CA18217C 
B5C55DF0 
98FA0510 
ECFB8504 
DB0933D7 
D8760273 
BAD946E2 
1A723C12 
B6150BDA 
287C5947 
CEE2D7AE 

86FFB7DC 
602646DE 
BO6A53ED 
CED4BB1B 
5983CA01 
46980C82 
OF1D45B7 
OF8037E0 
E 

3 


I 


B19CCB1 
F4860EE 


Informational 


C4C6628B 
8E3404DD 
E485B576 
5A899FA5 
98DA4836 
208552BB 
32905E46 


November 2007 


80DC1CD1 
EF 9519B3 
625E7EC6 
AE9F2411 
1C55D39A 
9ED52907 
2E36CE3B 


[2^6014 pi] + 


29024E08 
CD3A431B 
F44C42E9 
7CABIFEG 
69163FA8 
7096966D 
E39E772C 


6F4C52C9 
15728E5A 
58DBEFOA 
1E8C94E0 
3EC86A64 
08E24FAO0 
A787E6D7 
2583E9CA 
4E6BCO5D 
B81BDD76 
90A6COS8F 
C9751E76 
9027D831 
DB7F1447 
C64B92kEC 
B5A84031 
FF585AC5 
A79715EE 
A313D55C 
12BF2D5B 


DE2BCBF6 
8AAACA2D 
8AEA7157 
4A25619D 
521F2B18 
74E5AB31 
88719A10 
2AD44CE8 
99B2964F 
2170481C 
4DF435C9 
3DBA37BD 
179727B0 
E6CC254B 
FO32EA15 
900B1C9E 
4BD407B2 
F29BE328 
DA56C9EC 
0B7474D6 


95581718 
AD33170D 
5D060C7D 
CEE3D226 
177B200C 
43DB5BFC 
BDBA5B26 
DBBBC2DB 
A090C3A2 
D0069127 
34028492 
F8FF9406 
865A8918 
33205151 
D1721D03 
59E7C97F 
2B4154AA 
06A1D58B 
2EF29632 
E694F91E 
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7. 8192-bit Group 


This prime is: 


4743158 } 


Its hexadecimal value is: 


The generator is: 


Taylor, 


FFFFFFFF 
8A67CC74 
302B0A6D 
A637ED6B 
49286651 
FD24CF5F 
670C354E 
180E8603 
3995497C 
04507A33 
B3970F85 
1AD2EE6B 
BBE11757 
EOFD108E 
99C32718 
O4DE8EF9 
233BA186 
D5B05AA9 
36C3FAB4 
AD9E530E 


FFFFFFFF 
020BBEA6 
F25F1437 
OBFF5CB6 
ECE45B3D 
83655D23 
4ABC9804 
9B2783A2 
EA956AE5 
A85521AB 
A6E1E4C7 


C90FDAA2 
3B139B22 
4FE1356D 
F406B7ED 
C2007CB8 
DCA3AD96 
F1746C08 
ECO7A28F 
15D22618 
DF1CBA64 
ABF 5AE8C 


F1I2FFA06 
7A615D6C 
4B82D120 
6AF4E23C 
2E8EFC14 
515BE7ED 
93B4EA98 
D27C7026 
E5DB382F 


DA3EDBEB 
2BD7AF 42 
F482D7CE 
BEC7E8F3 
CC8F6D7E 
B7C5DA76 
387FE8D7 
6DBE1159 
3BC832B6 
5AEAF568 
22222E04 
2F8385DD 


CF 9B14ED 
6FB8F401 
6E74FEF6 
23A97A7E 
BF48E1D8 
F550AA3D 
6E3C0468 
74A3926F 
8D9DD300 
3423B474 
A4037C07 
FA9D4B7F 


D98A0864 
770988CO 
A9210801 
1A946834 
1FBECAA6 
1F612970 
8D8FDDC1 
C1D4DCB2 
413001AE 
44CE6CBA 
378CD2BF 
D55E702F 
36CC88BE 
14CC5ED2 
8AIFBFFO 
043E8F66 
12FEE5EAÀ 
7A1FA7BF 
2BF1C978 
13EB57A8 
A2C087E8 


6D2A13F8 
0846851D 
359046F4 
FC026E47 
60C980DD 


et al. 


3F44F82D 
F9AB4819 
EB879F92 
9558E447 
98EDD3DF 


19 


DF310EE0 
5DED7EA1 
4009438B 
5677E9AA 
FFFFFFFF 


2^8192 - 2^8128 - 1 * 2^64 * { 


2168C234 
514A0879 
6D51C245 
EE386BFB 
A163BF05 
1C62F356 
CA18217C 
B5C55DF0 
98FA0510 
ECFB8504 
DB0933D7 
D8760273 
BAD946E2 
1A723C12 
B6150BDA 
287C5947 
CEE2D7AE 

86FFB7DC 
602646DE 
BO6A53ED 
CED4BB1B 
5983CA01 
46980C82 
OF1D45B7 
0 

E 


I 


F8037E0 
B19CCB1 
3F4860EE 
38777CB6 
8AFC47ED 
238F16CB 
1A23F0C7 
79683303 
74AB6A36 
B1D510BD 
481C6CD7 
9E3050E2 
FFFFFFFF 


(decimal). 


Informational 


C4C6628B 
8E3404DD 
E485B576 
5A899FA5 
98DA4836 
208552BB 
32905E46 


November 2007 


80DC1CD1 
EF 9519B3 
625E7EC6 
AE9F2411 
1C55D39A 
9ED52907 
2E36CE3B 


[2^8062 pi] + 


29024E08 
CD3A431B 
F44C42E9 
7CABIFEG 
69163FA8 
7096966D 
E39E772C 


6F4C52C9 
15728E5A 
58DBEFOA 
1E8C94E0 
3EC86A64 
08E24FAO0 
A787E6D7 
2583E9CA 
4E6BCO5D 
B81BDD76 
90A6COS8F 
C9751E76 
9027D831 
DB7F1447 
C64B92kEC 
B5A84031 
FF585AC5 
A79715EE 
A313D55C 
12BF2D5B 
A932DF8C 
2576F 693 
E39D652D 
3473FC64 
ED5BDD3A 
45975899 
TEE74D73 
889A002E 
765694DF 


DE2BCBF6 
8AAACA2D 
8AEA7157 
4A25619D 
521F2B18 
74E5AB31 
88719A10 
2AD44CE8 
99B2964F 
2170481C 
4DF435C9 
3DBA37BD 
179727B0 
E6CC254B 
FO32EA15 
900B1C9E 
4BD407B2 
F29BE328 
DA56C9EC 
0 
D 


B7474D6 
8BEC4D0 
6BA42466 
E3FDB8BE 
6CEA306B 
062B3CF5 
A0255DC1 
FAF36BC3 
D5EE382B 
C81F56E8 


95581718 
AD33170D 
5D060C7D 
CEE3D226 
177B200C 
43DB5BFC 
BDBA5B26 
DBBBC2DB 
A090C3A2 
D0069127 
34028492 
F8FF9406 
865A8918 
33205151 
D1721D03 
59E7C97F 
2B4154AA 
06A1D58B 
2EF29632 
E694F91E 
73B931BA 
3AAB639C 
FC848AD9 
4BCBC886 
B3A278A6 
64F31CC5 
1ECFA268 
C9190DA6 
80B96E71 
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Appendix B. SRP Test Vectors 


The following test vectors demonstrate calculation of the verifier 
and premaster secret. 


I = "alice" 

P = "password123" 

S = BEB25379 D1A8581E B5A72767 3A2441EE 

N, g = «1024-bit parameters from Appendix A> 

k = 7556AA04 5AEF2CDD 07ABAFOF 665C3E81 8913186F 

x = 94B7555A ABE9127C C58CCF49 93DB6CF8 4D16C124 

V = 
7E273DE8 696FFCAF 4E337D05 B4B375BE BODDE156 9E8FAO00A 9886D812 
9BADAIF1 822223CA 1A605B53 0E379BA4 729FDC59 F105B478 7E5186F5 
C671085A 1447B52A 48CF1970 B4FB6F84 OOBBFACE BFBB1681 52E08AB5 
EA53D15C 1AFF87B2 B9DA6E04 E058AD51 CC72BFC9 033B564E 26480D78 
E955A5E2 9E7AB245 DB2BE315 E2099AFB 

a = 
60975527 035CF2AD 1989806F 0407210B C81EDC04 E2762A56 AFD529DD 
DA2D4393 

b= 
E487CB59 D31AC550 471E81F0 OF6928E0 1DDAO8E9 74A004F4 9E61F5D1 
05284D20 

A= 
61D5E490 F6F1B795 47B0704C 436F523D DOE560F0 C64115BB 72557EC4 
4352E890 3211C046 92272D8B 2D1A5358 A2CF1B6E OBFCF99F 921530EC 
8E393561 79EAE45E 42BA92AE ACED8251 71E1E8B9 AF6D9CO3 E1327F44 
BEO87EFO 6530E69F 66615261 EEF54073 CA11CF58 58FOEDFD FEIS5EFEA 
B349EF5D 76988A36 72FAC47B 0769447B 
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BD0C6151 
BAF38964 
6C6DA044 
37089E6F 
EB4012B7 


CE38B959 
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2C692C0C 
DC46A067 
53728610 
9C6059F3 
D7665238 


3487DA98 


<premaster secret> = 


Appendix C. 


BODC82BA 
233861E3 
41BB59B6 
3499B200 
C346D7E4 


BCF30674 
59B48220 
D5979B5C 
210DCC1F 
74B2 9EDE 


B6D041FA 
0DD125B9 
DOC6DDB5 
88838E7A 
A8ES3FBOO 


554ED47D 


AE450C02 
F7C4693C 
00A172B4 
10EB3394 
8A469F FE 
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8B318885 
00030B33 
4B117B58 
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87745E79 
9AE12B0A 
A2A5903A 
3CD67FC8 
CA686E5A 


4916A1E7 
236F99D9 
D7D82C7F 
1EB76840 


462EF019 


90A3381F 
6F67809F 
OBDCAF 8A 
8A2F39A4 


November 2007 


TAF 4 6AE1 
B681CBF8 
8DEB75CE 
910440B1 


63B387AA 
0876E2D0 
709585EB 
BESBEC4E 


05393011 
783 7EC99 
7BD4FBAA 
B27AAEAE 


F271A10D 
13800D6C 
2AFAFA8F 
C0A3212D 
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